Thank you, @duncandewhurst, for the changes. I think this is ready for James to review again, right?
And should we add a link to the new page from the Determine data needs section? (particularly to the "Whether to publish a change history" item)

And should we add a link to the new page from the Determine data needs section? (particularly to the "Whether to publish a change history" item)

Yes!

@yolile, @jpmckinney are you happy for me to pick up and complete this PR?

@duncandewhurst Yes, I'm!

To-do:

• Review built version of documentation
• Check guidance on setting .date in guidance on hashing (no last modified date)
• Cherry pick updates to amendments example and update JSON directives in example 3

@jpmckinney this is ready for your review. I've made the changes suggested in your last comment, simplified the examples in line with our discussions elsewhere, and made various copy edits for consistency and clarity.

Two things to flag:

1. The old easy releases guidance describes how to use a hash function to update release id in the absence of a last modified date. However, it doesn't explain how to set date. In the new individual releases guidance, I've recommended setting date to the date the release was generated (i.e. the date the user downloaded the data). Happy to discuss if there might be a better approach.
2. In the individual releases guidance, I've preserved the recommendation to prefix .id with the ocid so that users don't need to filter on ocid to find releases belonging to the same contracting process. However, I'm inclined to remove that recommendation so that the examples align with the rule that .id need only be unique within the scope of the contracting process. It seems like more work to filter on part of a field (.id) than on a separate field. What do you think?

Edit: I forgot to mention, this PR includes some commits from #1661 which is also awaiting review. Whichever is reviewed first, I'll make the necessary updates to the other one.

In the individual releases guidance, I've preserved the recommendation to prefix .id with the ocid so that users don't need to filter on ocid to find releases belonging to the same contracting process. However, I'm inclined to remove that recommendation so that the examples align with the rule that .id need only be unique within the scope of the contracting process. It seems like more work to filter on part of a field (.id) than on a separate field. What do you think?

Agree - I prefer your suggested simplification.

Great. I've done that in c848382

Noting that amendments.md includes changes from #1661, but my suggested edits in that PR don't overlap, so there shouldn't be a merge conflict. amendments.md has an extra commits in this PR, which can be reviewed independently:

• 3c64c95#diff-d3ab3df28ed0eba11bf5bcc05a619b2e8048d802f73ce950116f800fba79dd6d (small)
• 104d2a4#diff-d3ab3df28ed0eba11bf5bcc05a619b2e8048d802f73ce950116f800fba79dd6d (merge)
• 0cc23e1#diff-d3ab3df28ed0eba11bf5bcc05a619b2e8048d802f73ce950116f800fba79dd6d
• 6f51570#diff-d3ab3df28ed0eba11bf5bcc05a619b2e8048d802f73ce950116f800fba79dd6d